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(54) Memory security device 



(57) A senniconductor integrated circuit includes a 
processorfor executing application code from a mennory 
and a verifier processor arranged to receive the appli- 
cation code via the same internal bus as the processor. 



The verifier processor perfomns a verification function to 
check that the application code is authentic. The verifier 
processor runs autonomously and cannot be spoofed 
as it receives the application code via the same internal 
bus as the main processor. 
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Description 

FIELD OF THE INVENTION 

[0001 ] The present invention relates to a memory se- 
curity device, and in particular to the security of flash 
memory used in conditional access devices. 

BACKGROUND OF THE INVENTION 

[0002] In conditional access devices for pay televi- 
sion, or any other device using memory and requiring 
security, there is a need to provide flash memory but to 
avoid hacking. Hacking is the unauthorised placing of 
software in memory to override security features. 
[0003] A known way of attempting to prevent hacking 
is to use some form of checking instructed by ROM 
memory to ensure that an application code stored in 
flash memory is correct. Such a device is shown in Fig- 
ure 1. 

[0004] A flash memory 2 has a boot sector 6 and an 
application sector 16. A GPU 10 is arranged to run ap- 
plication code from the flash memory 2 retrieved over 
an interface 12 via bus 8 EMI 20 and bus 18. The secu- 
rity is provided by the fact that CPU 1 0 boots from a boot 
ROM 3 which contains code to check the boot sector 6 
of the flash memory. This is done once by the CPU pro- 
ducing a function of the code in the boot sector and com- 
paring with a stored signature on startup. The CPU then 
jumps to the code in the boot sector 6 if it passes the 
check. However, we have appreciated that there is a rel- 
atively simple way of hacking such a security arrange- 
ment. When the CPU 10 boots up using code from the 
ROM 3, the CPU checks that the code in the boot sector 
6 is correct. The weakness is that the process of power 
on, CPU boot and checking the flash takes a predictable 
number of clock cycles of the CPU clock. Thus to hack 
the system, a hacker places code in an unchecked part 
of the flash memory 2 and forces the CPU to read from 
that part of the memory after a predetermined number 
of clock cycles by fixing an external address line. 
[0005] The CPU 10 thereafter runs from unchecked 
code and no further checks are conducted, because the 
verification of code is only conducted on boot up from 
the ROM 3. 

[0006] We have appreciated the problem that memo- 
ry storing application code within devices can be inse- 
cure and prone to hacking by storing unauthorised code. 

SUMMARY OF THE INVENTION 

[0007] The invention is defined in the independent 
claims with preferred features set out in dependent 
claims. 

[0008] An embodiment of the invention comprises an 
additional processor termed a verifier processor and 
code arranged to read data from a memory to be 
checked, to produce a function of that data, and to verify 



that function of the data against a stored code. The ver- 
ifier processor is on the same device and has the same 
external interfaces as a CPU which runs application 
code from the memory. The advantage of using an ad- 
5 ditional processor on the same device as a CPU is that 
the system cannot be hacked by changing code stored 
in memory as the additional processor would then also 
receive changed application code which would not be 
verified. 

10 [0009] The verifier processor is arranged to continu- 
ally check the flash memory whilst the CPU executes 
from the flash memory. If the address lines of the device 
were redirected so that the CPU runs from unauthorised 
code, then the verifier processor would also be redirect- 
15 ed to that unauthorised code which would not pass the 
check. 

[0010] The additional processor preferably produces 
a hash of the application code stored in memory and 
uses signature techniques to verify the application code. 
20 [0011] The embodiment thus comprises an additional 
processor function which runs independently of a CPU 
but is within the same integrated circuit as that CPU and 
shares the same bus. The processor function analyses 
the application code applied to the CPU and, if not au- 
25 thentic, issues a reset signal to reset the integrated cir- 
cuit. 

BRIEF DESCRIPTION OF THE FIGURES 

30 [0012] An embodiment of the invention will now be de- 
scribed by way of example only and with reference to 
the figures in which: 

Figure 1 : shows a known CPU memory arrangement 
35 for checking code; 

Figure 2: shows an arrangement of a memory check- 
ing processor embodying the invention; 
Figure 3: shows the memory checking processor of 
Figure 2 in greater detail. 

40 

DESCRIPTION OF AN EMBODIMENT 

[0013] The Autonomous Flash Checker (AFC) com- 
prises a processor whose purpose is to check or verify 

45 that application code stored in a flash memory 2 for ex- 
ecution by a CPU 10 is authentic and has not been 
changed or "hacked". Flash memory is used in many 
devices, but the preferred embodiment is a conditional 
access system for television broadcast. In such systems 

50 it is important that application software stored in flash 
memory is authentic and has not been changed in any 
way by a hacker. Such changes could be to run code 
whereby the system decrypts received broadcast sig- 
nals without requiring payment by the user. The AFC 

55 processor 22 thus analyses the application code stored 
in flash memory to ensure the code is authentic. 
[0014] An integrated circuit embodying the invention 
is shown in Figure 2, labelled device B. A processor 
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(CPU) 1 0 is connected via an internal bus 8 and an ex- 
ternal interface 20 via external connections on an inter- 
face 20 via external connections on an interface 12 and 
bus 18 to a flash memory 2. The flash memory 2 con- 
tains application code in a boot sector 6 for execution 
by the CPU 10, signature portion 14 and an application 
sector 16. The signature portion contains a signature 
that is a function of the application code in the boot sec- 
tor itself and is used for verification. 
[0015] On power up of integrated circuit B, the CPU 
1 0 is directed to the boot vector 4 of the flash memory 
2 on a first integrated circuit, labelled circuit A. The ap- 
plication code is then retrieved over bus 1 8 and external 
memory interface 20 via internal bus 8 by the CPU 10 
which executes the code. The application code is stored 
in a signed code portion 6 of the flash memory. It is noted 
that the AFC 22 is connected to the same internal bus 
8 and external connections as the CPU , and so retrieves 
exactly the same code as the CPU without possibility of 
external interference. This is because the CPU, AFC 
processor and interconnect bus are all part of the same 
integrated circuit, labelled device B. 
[0016] The CPU 10 and flash memory 2 operate in a 
known fashion, unless the AFC processor determines 
that the application code in flash memory 2 is not au- 
thentic, however, it impairs operation of the device B by 
using a reset causing the device to reset and the boot 
sequence is restarted. Thus, if the application code has 
been tampered with, the set top box will repeatedly re- 
boot and will not function to decrypt received TV signals. 
Other forms of impairing the operation of device B could 
be used such as disabling or stopping the device clock 
or otherwise limiting the functionality of the device. 
[001 7] The operation of the AFC processor itself is by 
producing a hash function and a signature of the appli- 
cation code using a public key from a public key store 
26 selected by antifuse 24 (Figure 2) as will now be de- 
scribed with reference to Figures 2 and 3. 
[0018] The AFC 22 comprises a verifier processor 
such as a Rise processor 30 which executes code 
stored in code ROM 40 and uses RAM 12 for temporary 
storage. The code in code ROM 40 is only accessible 
by the verifier processor and instructs the Rise proces- 
sor 30 to undertake the following steps: 

1 . Produce a hash of application code received from 

the flash memory. 

2. Produce a signature function of the hashed code. 

3. Verify that the signature is correct. 

[0019] The verifier processor is not externally acces- 
sible other than in specific ways described later, and so 
cannot be hacked and only runs from the code in ROM 
which cannot be changed. 

[0020] If the signature is correct then the application 
code in flash memory is deemed authentic. 
[0021] The steps set out above are undertaken con- 
tinually; each set of steps comprising a cycle of the ver- 



ifier processor. 

[0022] During each cyclethe CPU 1 0 continues to op- 
erate as normal in retrieving and executing the applica- 
tion code over the same internal bus 8 as used by the 
5 verifier processor 30 over line 38. Accordingly, to avoid 
reducing the performance of the CPU 10, the verifier 
processor requests application code from the memory 
less frequently than the CPU, for example the verifier 
requests code once every 1,000 to 10,000 CPU re- 
quests. Also, the verifier requests are at pseudo random 
locations and at pseudo random times. This helps ob- 
scure the verifier requests amongst the CPU requests. 
The requests made at external connections at interface 
12 for data from the flash thus comprise CPU requests 
and pseudo random requests at pseudo random times 
comparatively infrequently mixed together. 
It is thus all but impossible for a hacker to determine how 
to spoof the external address lines to direct the CPU to 
hacked code but the verifier to genuine code. The use 
of pseudo random locations and times makes spoofing 
harder. The requests to the flash memory themselves 
are indistinguishable, whether made by the CPU or ver- 
ifier processor. 

[0023] The first step of producing a hash of the appli- 
cation code uses a flash read circuit which is instructed 
by RISC processor 30 to retrieve the code over bus 8. 
The application code can be read sequentially or in cir- 
cular or pseudo random fashion as specified by the code 
in ROM, and is provided to the RISC processor 30 over 
line 38. 

The hash function can be any one-way hash function 
which has the advantage that any small change in the 
application code will result in a large change in the 
hashed code, but is mathematically all but impossible to 
derive multiple changes that could be made to the ap- 
plication code such that the hashed code is unchanged. 
Preferably, the RISC processor 30 continually receives 
the application code from the flash in a pseudo-random 
read pattern, and uses a know hash function such as 
MD5. 

[0024] On completion ofthe hash function, the second 
step is to produce a signature function of the hashed 
code. To do this, the RISC processor produces a func- 
tion F (hashed code, public key) where the public key is 
selected from the public key store 26 by antifuse 24 and 
provided at 42. The signature of the application code is 
retrieved from signature location 14 (Figure 2) in the 
flash (having been created and prestored using the cor- 
responding private key). A second function G (public 
key, signature) is then produced. The antifuses are ar- 
ranged to select only one of a plurality of keys in the key 
store 26. This allows a generic device B to be created 
but to be tailored by selecting just one of possible keys. 
The antifuses are known and are irreversible fuses. 
[0025] The third step is then to verify the hashed code 
against the signature by the standard digital signature 
technique of comparing F (hashed code, public key) and 
G (public key, signature). The preferred algorithm is 
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DSA. 

Provided that the signature is verified, then no action Is 
taken. If the application code does not verify the signa- 
ture, however, an innpair function results at 48 a chip 
reset is issued over line 50, preventing the chip operat- 
ing further. 

[0026] We have also appreciated that there may be a 
need to download new (authentic) code to the flash 
nnemory and that this should be provided for so that the 
AFC does not erroneously reject this new code. To allow 
this, the verifier processor must be stopped for M min- 
utes, but again this could leave the possibility of a hack 
in which the AFC is permanently stopped. To prevent 
this, the code in ROM 40 causes the verifier processor 
to automatically issue a chip reset after M minutes, and 
starts the verification at the beginning of the new code 
in flash memory. 

[0027] The only commands available to the CPU 10 
to control the verifier processor 22 are: STOP, RE- 
START, PAUSE. Thereafter, the operation of the AFC 
processor is autonomous and largely in hardware, with 
the only software being in ROM 40 or RAM 42 which are 
only accessible by the RISC processor 30. 
[0028] We have appreciated, however, that these 
commands need to be available to the CPU to avoid 
contention and allow flash memory updates, but could 
open the possibility of hacks which permanently pause 
or stop the AFC or continually reset. For that reason, 
further preferred features are included. 
[0029] A first preferred feature is to allow the CPU 1 0 
to pausethe verifier processorto avoid contention. How- 
ever, we have appreciated that this could allow a hack 
in which the AFC is permanently paused. So the code 
in ROM 40 is configured only to allow N pauses in one 
cycle of checking the flash memory. Each pause can be 
around 1 second. If the count N is exceeded, a chip reset 
signal is sent. 

[0030] A further possible hack would be to block re- 
quests made by the verifier processor for code from the 
flash such thatthe verification process nevercompletes. 
To prevent this, a watchdog function is incorporated in 
the code in ROM 40 such that a reset is issued if a cycle 
does not complete in a given time. The given time is pre- 
dictable as it is known how long should be taken for a 
cycle and so this is programmed in ROM. 
[0031] Itcould also be possible to hacktheflash mem- 
ory code such that the CPU continually instructs the ver- 
ifier processorto stop and restart. To avoid this, the code 
in ROM does not allowthe verifier processorto stop after 
a restart request so that a whole cycle of verification is 
conducted. 

[0032] It is noted that the verifier processor has ac- 
cess to RAM 42. This RAM is also on the same device 
as the CPU, ROM 40 and verifier processsor so as to 
avoid the possibility of hacking this RAM which Is used 
to store temporary values during execution of the veri- 
fication code in ROM 40. The verifier processor only has 
two external connections; to retrieve data and to issue 



resets. The reset is issued to the device B itself and so 
cannot be hacked and the retrieval of code uses the 
same bus as the CPU and so if hacked would not be 
verified as previously described. 

5 

Claims 

1 . A semiconductor integrated circuit arranged to ex- 
10 ecute application code received from a memory via 

external connections, comprising: a processor for 
executing application code from the memory; an in- 
ternal bus within the integrated circuit for providing 
the application code to the processor from the ex- 
15 ternal connections; and characterised by a verifier 
processor arranged to receive the application code 
via the internal bus, wherein the verifier processor 
is arranged to process the application code using a 
verification function and to impair the function of the 
20 integrated circuit in the event that the application 
code does not satisfy the verification function. 

2. A semiconductor integrated circuit according to 
claim 1 , wherein the verification function includes a 

25 hash function on the application code. 

3. A semiconductor integrated circuit according to 
claim 1 or 2, wherein the verifier processor is ar- 
ranged to receive a stored secret from the memory 

30 and the verification function is a comparison of the 
secret and the processed application code. 

4. A semiconductor integrated circuit according to any 

preceding claim, wherein the verification function 
35 comprises hashing the application code to produce 
hashed code, retrieving a signature of the codefrom 
a signature store within the memory and verifying 
the hashed code and signature using a public key. 

40 5. A semiconductor according to any preceding claim, 
wherein the verifier processor has a pause input ar- 
ranged to receive a pause signal from the proces- 
sor, and is arranged to impair the function of the in- 
tegrated circuit if greater than a given number of 

45 pause signals are received in a given time. 

6. A semiconductor integrated circuit according to any 
preceding claim, wherein the verifier processor has 
a stop input arranged to receive a stop signal from 

50 the processor, and is arranged to issue impair the 
function of the integrated circuit a given time period 
after receiving a stop signal. 

7. A semiconductor integrated circuit according to any 
55 preceding claim, wherein the verifier processor has 

a stop input and is arranged to restart a given time 
period after a stop, and arranged not to stop again 
until completing the verification function on the code 
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at least once. 

8. A semiconductor integrated circuit according to any 
preceding claim, wlierein the verifier processor is 
arranged to impair the function of the integrated cir- 5 
cult if the verification function is not completed with- 
in a predetermined time. 

9. A semiconductor integrated circuit according to any 
preceding claim, wherein the verifier processor re- io 
quests portions application code from the flash 
memory at intervals between requests by the proc- 
essor for portions of the application code. 

10. A semiconductor integrated circuit according to 15 
claim 9, wherein the verifier processor requests por- 
tions of application code less frequent intervals than 

the processor. 

11. A semiconductor integrated circuit according to 20 
claim 9 or 10, wherein the verifier processor is ar- 
ranged to request portions of application code at 
pseudo random times. 

12. A semiconductor integrated circuit according to 25 

claim 9, 10 or 11 , wherein the verifier processor is 
arranged to request portions of application code 
from pseudo random locations in the memory. 

1 3. A semiconductor integrated circuit according to any 30 
preceding claim, comprising a ROM arranged on 

the same integrated circuit, wherein the verification 
function is defined by the code in the ROM. 

14. A semiconductor integrated circuit according to 35 
claim 13, wherein the ROM is only accessible by 
the verifier processor. 

15. A semiconductor integrated circuit according to 
claim 13 or 14, further comprising a RAM on the 40 
same integrated circuit for storage of temporary val- 
ues when executing the verification function. 

16. A semiconductor integrated circuit according to any 
preceding claim, wherein impairing the function of ^5 
the integrated circuit comprises resetting the circuit. 
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